One solution for IPv6 addressing and routing

The addressing/routing model presented in this article is one more attempt to go beyond simple ad-hoc in improving IP routing. The model implements a vision of “ocean of connectivity and absolute minimum of support”. By realigning basic routing primitives I sketch a routing model that is simple, flexible, universal, self-maintained and self-reconfigurable, serves both classical wired, new wireless and envisioned ubiquitous internet infrastructure. The resulting scheme is applicable both locally and globally. Computational complexity estimates for the proposed model are very promising. The current state of IPv6 is depressing. Rates of IPv6 adoption resemble more of “IPv6 is technology of the future and always will be” than of the fax effect in action. One of particular obstacles preventing IPv6 adoption is lack of multihoming support. IPv6 route aggregation technology relies heavily on strict addressing hierarchies, which are not multihoming-friendly. The latest result by the multi6 IETF working group is RFC 4219 [25], the standard questionnaire for proposed IPv6 multihoming solutions. The only undoubtable IPv6 advantage is “just more bits”. By all other means, including the routing technology, IPv6 is just “IPv4+”: RIP, OSPF and BGP for IPv6 are carbon copies of their originals. Because of the aforementioned considerations, I will skip any IPv6 backward compatibility issues (because the current IPv6 legacy just does not worth the price). The objective of the proposed model is: given a link (2nd) layer, to configure automatically network (3rd) layer, which is able to provide services with some practical QoS to the transport (4th) layer. Thus, 3rd layer has to be self-deployed, self-maintained and self-reconfigured. Scope of the paper is limited to the 3rd layer of the TCP/IP stack, sometimes addressing changes induced on the 4th layer. No practical migration plan or commercial issues are considered. Special instruction to the reader: although the most of design patterns used are well-known (CIDR, multiple addresses, IX-rooted address assignments, etc), the reader has to be warned that in this particular architecture